profile
viewpoint
leo leojonathanoh The Oh Brothers high-land https://theohbrothers.com do great things

leojonathanoh/docker-certbot-dns-cron 2

Dockerized Certbot with DNS Plugins, with cron, deploy, email alert capabilities 🐳

leojonathanoh/asuswrt-merlin 0

Enhanced version of Asus's router firmware (Asuswrt)

leojonathanoh/client_golang 0

Prometheus instrumentation library for Go applications

leojonathanoh/Compile-SourceScript 0

A PowerShell module for compiling SourceMod (.sp) and AMX Mod X (.sma) plugin source files for Source / Goldsource games.

leojonathanoh/Csv2Ldif 0

Convert csv to ldif format for easy test user creation (ex.: contoso.com)

leojonathanoh/docker-alpine 0

Dockerized alpine with useful tools 🐳

leojonathanoh/docker-alpine-cron 0

Lightweight alpine with busybox crond 🐳

leojonathanoh/docker-ansible 0

Dockerized ansible alpine image with useful tools 🐳

leojonathanoh/docker-go-tools 0

A dockerized workflow that decouples the go runtime and tools from the developer's OS. 🐳

leojonathanoh/docker-hlstatsxce-daemon 0

Docker image for the HLStatsX:CE perl daemon 🐳

pull request commentstartersclan/docker-sourceservers

Update CircleCI build badges links for CircleCI new UI update

yes, circleci determines ci repo’s visibility based on the visibility of the github repo. I checked and there is no setting on the new UI to control visibility of the ci repo. So it’s that, whether it’s deliberate or not is out of the picture but it is not hard to figure.

joeltimothyoh

comment created time in 8 days

pull request commentstartersclan/docker-sourceservers

Update CircleCI build badges links for CircleCI new UI update

One thing though. As of the new UI update, it doesn’t look like build logs are publicly viewable without a sign-in to CircleCI. @leojonathanoh

strange. Maybe it’s something to do with marking the repo public or private

joeltimothyoh

comment created time in 11 days

created tagstartersclan/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha 0151d18fa1d712986144c94992de8d9065b60164

Docs: Update readme on environment variables: LOG_LEVEL

view details

Leo

commit sha 888aae4d4f07081c81e074e207208f9eac91b175

Merge pull request #10 from leojonathanoh/dev Docs: Update readme on environment variables: LOG_LEVEL

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 0151d18fa1d712986144c94992de8d9065b60164

Docs: Update readme on environment variables: LOG_LEVEL

view details

push time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha 1db899f00ba899b123b10cf8284d0efd699996d9

Refactor: Split github workflow into ci-branches and ci-tags

view details

Leo

commit sha 4db9b194c0092efdb26c2c71b93f21bee1b7cb64

Merge pull request #9 from leojonathanoh/dev Refactor: Split github workflow into ci-branches and ci-tags

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 1db899f00ba899b123b10cf8284d0efd699996d9

Refactor: Split github workflow into ci-branches and ci-tags

view details

push time in 21 days

created tagleojonathanoh/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

delete tag leojonathanoh/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

created tagleojonathanoh/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 8eb7da0faaf698a6c24a2bae6a3cf0fca4099391

Refactor: Split github workflow into ci-branches and ci-tags

view details

push time in 21 days

delete tag leojonathanoh/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

created tagleojonathanoh/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 41171ca920dac6a4e355aa4c17e169b80b5a3904

Refactor: Split github workflow into ci-branches and ci-tags

view details

push time in 21 days

delete tag leojonathanoh/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

delete tag startersclan/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

PR opened startersclan/docker-hlstatsxce-daemon

Refactor: Split github workflow into ci-branches and ci-tags

Remove ci for PRs and splits ci into branches and tags.

+1408 -166

0 comment

6 changed files

pr created time in 21 days

created tagleojonathanoh/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

delete tag leojonathanoh/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

created tagleojonathanoh/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

delete tag leojonathanoh/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha d8ed518f3ce4ce5c7e5e99abaf2b1be22512a215

Refactor: Split github workflow into ci-branches and ci-tags

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha e1d171437bbaaa2a81d16d9b8f2cbc1fb172b443

Refactor: Split workflow into ci-branches and ci-tags

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha a79c26fc42650a64b2e50588832b85fe443314fe

Refactor: Split workflow into ci-branches and ci-tags

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 32d811d39df77120c5af00f213328994078aad2a

Refactor: Split workflow into ci-master-pr and ci-release

view details

push time in 21 days

created tagstartersclan/docker-hlstatsxce-daemon

tagv1.6.19

Docker image for the HLStatsX:CE perl daemon 🐳

created time in 21 days

delete tag startersclan/docker-hlstatsxce-daemon

delete tag : v1.6.19

delete time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha 5b3d5ad42d8a23fd6e414c2e7438d7c6f9bf84ea

Remove unused $VARAINTS_VERSION in VARIANTS definitions

view details

Leo

commit sha c7735592bcae440dc97a5385548226c92231c3d2

Rename generator variable variables['goelitecity_url'] to variables['geolitecity_url']

view details

Leo

commit sha 3d5db865cc6feab6030f80daacb2af95358b284e

Merge pull request #8 from leojonathanoh/dev Chore: Cleanup and rename generator variables

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 5b3d5ad42d8a23fd6e414c2e7438d7c6f9bf84ea

Remove unused $VARAINTS_VERSION in VARIANTS definitions

view details

Leo

commit sha c7735592bcae440dc97a5385548226c92231c3d2

Rename generator variable variables['goelitecity_url'] to variables['geolitecity_url']

view details

push time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha d99174b7e3e5e73f0a92c471c5bddc4b3aad4681

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

Leo

commit sha 8e923076109371e57bdc7c6ba49bd6413444ad2b

Merge pull request #7 from leojonathanoh/dev Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

issue closedstartersclan/docker-hlstatsxce-daemon

GeoIP2 databases no longer a public resource

Background

According to https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/, GeoIP2 databases no longer distributed publicly.

Bug

The change breaks all GeoIP2 image builds. As seen in psat workflows:

  • https://github.com/startersclan/docker-hlstatsxce-daemon/actions/runs/168687148
  • https://github.com/startersclan/docker-hlstatsxce-daemon/actions/runs/168709170

closed time in 21 days

leojonathanoh

issue closedstartersclan/docker-hlstatsxce-daemon

Improve clarity of order of reading of configuration options in readme

Bug

Readme isn't clear about the order of reading of configuration options.

Suggested

Actual order of reading of configuration options:

  1. Default config file ./hlstats.conf
    • https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1739-L1784
  2. Command line parameters
    • https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1792-L1829
  3. (N.A. since bugged) Custom config file specified by command line parameter --configfile.
    • Doesn't work because of a bug explained in https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1821-L1826
  4. Database configuration from hlstats_options table:
    • directives: https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1755-L1781)
    • call: https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1882)

closed time in 21 days

leojonathanoh

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha d99174b7e3e5e73f0a92c471c5bddc4b3aad4681

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha b84cbb88ff5d84a56667489ee2e2ef3c066419f6

Refactor: Improve clarity of order of reading of configuration options in readme

view details

Leo

commit sha b7eddec409882965034a997f3640d889da364f31

Merge pull request #5 from leojonathanoh/refactor/improve-clarity-of-order-of-reading-of-configuration-options-in-readme Refactor: Update readme on order of reading of configuration options

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha f03ab6cc7dc22e49beefcf24fbc6d5df2de64267

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 350cb6816557207c25ccd95fbf660fa41679cfab

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 34057cfe50c5205d8082c4ac35250e3013d2ea77

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha c42d342c9c9688181e18c743afbfeb6535589636

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha c0d6f572a049aaf87afaeeede4a8c9d8f0b48048

Fix: Add secret `MAXMIND_LICENSE_KEY` to be able to download GeoLite2-City database

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 3a80a10848b3329503607881b0d1ef0f135bde6c

Merge branch 'dev' into master

view details

Leo

commit sha 692a1b048d7e1e62d51622142d9139cae31bc1f7

Fix `LOG_LEVEL` environment variable to map onto command line argument -dd in docker-entrypoint.sh

view details

Leo

commit sha b13fabbdd9903690f73f644b4a6274bef9671a84

Merge pull request #4 from leojonathanoh/fix/log-level-environment-variable-to-map-onto-command-line-argument-dd-in-docker-entrypoint.sh Fix `LOG_LEVEL` environment variable to map onto command line argument -dd in docker-entrypoint.sh

view details

push time in 21 days

issue openedstartersclan/docker-hlstatsxce-daemon

GeoIP2 databases no longer a public resource

According to https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/, GeoIP2 databases no longer distributed publicly.

This will break all GeoIP2 image builds. As seen in workflows:

  • https://github.com/startersclan/docker-hlstatsxce-daemon/actions/runs/168687148
  • https://github.com/startersclan/docker-hlstatsxce-daemon/actions/runs/168709170

created time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha b84cbb88ff5d84a56667489ee2e2ef3c066419f6

Refactor: Improve clarity of order of reading of configuration options in readme

view details

push time in 21 days

push eventleojonathanoh/docker-hlstatsxce-daemon

push time in 21 days

push eventstartersclan/docker-hlstatsxce-daemon

Leo

commit sha 692a1b048d7e1e62d51622142d9139cae31bc1f7

Fix `LOG_LEVEL` environment variable to map onto command line argument -dd in docker-entrypoint.sh

view details

Leo

commit sha b13fabbdd9903690f73f644b4a6274bef9671a84

Merge pull request #4 from leojonathanoh/fix/log-level-environment-variable-to-map-onto-command-line-argument-dd-in-docker-entrypoint.sh Fix `LOG_LEVEL` environment variable to map onto command line argument -dd in docker-entrypoint.sh

view details

push time in 21 days

issue closedstartersclan/docker-hlstatsxce-daemon

`LOG_LEVEL` env var does not allow verbose logging

Bug

LOG_LEVEL env var does not allow verbose logging.

Suggested

LOG_LEVEL env var does allows verbose logging.

closed time in 21 days

leojonathanoh

push eventleojonathanoh/docker-hlstatsxce-daemon

Leo

commit sha 692a1b048d7e1e62d51622142d9139cae31bc1f7

Fix `LOG_LEVEL` environment variable to map onto command line argument -dd in docker-entrypoint.sh

view details

push time in 21 days

issue openedstartersclan/docker-hlstatsxce-daemon

`LOG_LEVEL` env var does not allow verbose logging

Bug

LOG_LEVEL env var does not allow verbose logging.

Suggested

LOG_LEVEL env var does allows verbose logging.

created time in 21 days

issue openedstartersclan/docker-hlstatsxce-daemon

Improve clarity of order of reading of configuration options in readme

Bug

Readme isn't clear about the order of reading of configuration options.

Suggested

Actual order of reading of configuration options:

  1. Default config file ./hlstats.conf
    • https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1739-L1784
  2. Command line parameters
    • https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1792-L1829
  3. (N.A. since bugged) Custom config file specified by command line parameter --configfile.
    • Doesn't work because of a bug explained in https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1821-L1826
  4. Database configuration from hlstats_options table:
    • directives: https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1755-L1781)
    • call: https://github.com/startersclan/hlstatsx-community-edition/blob/965453909e1d28aed3abfca7f93b6c1b27a7f75d/scripts/hlstats.pl#L1882)

created time in 21 days

issue commentrook/rook

Bug: Disk usage not reclaimed when files are deleted

I assume that this issue has been fixed with rook v1.3.2 which uses ceph-csi v2.1.0 which includes https://github.com/ceph/ceph-csi/pull/848

leojonathanoh

comment created time in 2 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

Yes, Compile-SourceScript is itself a convenient wrapper that is designed to support invocation of the two mods’ compiler wrappers; not the most elegant way for compiling plugins, but at least supported by the module that makes the module predictable to use. Yet, what adding -ScriptingDirectory would do is having to prevent compiler wrappers from being invoked unless the directory containing the specified plugin source file is itself like the default scripting directory - that is, containing the compiler, compiler wrapper, and include files, as well as other plugins source files with their include files as well. As though this isn’t confusing enough, there’s too the relative compiled directory which will be created and contain compiled plugins, as well as the plugin directory for installation of the plugin, both of which would have to exist in the directory containing the specified plugin source file.

If arguments for benefits of using Compile-SourceScript as a full replacement wrapper is not enough, then there should also be arguments against supporting native compiler wrappers:

First, the wrappers' behavior are inconsistent across platforms. While it is native to amxmodx and sourcemod, I believe most developers would be frustrated at the difference in behavior between amxmodx's compile.exe vs. compile.sh, where the latter supports flags that former doesn't.

Second, the wrappers do not emit exit codes correctly. It is the responsibility of the native wrapper to collate each compile job's exit code and emit a final batch exit code that represents the fail jobs' exit codes. However compile.exe and compile.sh are not complying to this behavior. As seen in https://github.com/startersclan/Compile-SourceScript/pull/7#issuecomment-623281844 when using compile.exe, no non-zero exit code is emitted when compilation of any plugin fails. Similarly compile.sh emits the exit code of the last shell statement, which could lead to false positives (i.e. false success): for instance, when there are earlier failed compilation and a successful finalmost compilation, instead of emitting a non-zero exit code, compile.sh emits an exit code of 0.

If Compile-SourceScript is going to be easy and predictable to use, then even the parameters themselves should be given names that accurately represent the functionality they serve. As I’ve described earlier, the scripting directory in both amxmodx and sourcemod isn’t simply a directory containing plugin source files, a.k.a. scripts as they would call, but is one containing the compiler and all default include files that come with the mods. With that in mind, a custom scripting directory would actually be one containing those very files themselves. That means, by convention, that the location of the source file cannot actually live outside a scripting directory. Seeing -ScriptingDirectory as separate from the plugin source file and especially allowing specification of the two as separate parameters goes against the convention set by the mods and would very likely come across as confusing to users of this module, as it has been for me.

As I mentioned in https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-619727381 and https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-623292129, the scripting directory contain includes (common dependencies, which in most cases should be unaltered), the compiler and the compiler wrapper, and the plugin source code. However, if the plugin consumes unmodified includes, and does not vendor its own custom includes, then it's source code can live outside of the scripting directory and preferably in its own repo.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

You may wish to go over the thread carefully starting from #2 (comment).

Let me break my responses to https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-623198202 down.

I know I worked on this PR. And you happen to be working on it right now. Yet, the more time I spend supporting this feature request, the more it seems an unnecessary and confusing feature to have.

Speaking of the default behavior of Compile-SourceScript notwithstanding this PR, when a plugin source file is specified without -ScriptingDirectory, the scripting directory is automatically determined to be the directory containing the specified file. The default behavior therefore already allows flexibility in how the scripting directory is named, with the exception of relative directories compiled and plugins which will be automatically created and cannot be customized.

The first issue with -ScriptingDirectory is how it actually requires -SkipWrapper to be passed. If the switch isn’t passed, compilation of the specified plugin source file would not occur correctly since the wrapper scripts simply invoke the compiler to compile all plugins in the work directory, in which case would be determined to be the specified scripting directory which would not include compilation of the specified source file. The compiler wrapper script in amxmod compiles all plugin source files existing within the very directory it is in, a convention adopted and also followed by sourcemod‘s own compiler wrapper. Conventions usually exist for a reason, and I think they should be followed closely for the sake of the community who may stumble across this convenient wrapper solution. Yes, Compile-SourceScript is itself a convenient wrapper that is designed to support invocation of the two mods’ compiler wrappers; not the most elegant way for compiling plugins, but at least supported by the module that makes the module predictable to use. Yet, what adding -ScriptingDirectory would do is having to prevent compiler wrappers from being invoked unless the directory containing the specified plugin source file is itself like the default scripting directory - that is, containing the compiler, compiler wrapper, and include files, as well as other plugins source files with their include files as well. As though this isn’t confusing enough, there’s too the relative compiled directory which will be created and contain compiled plugins, as well as the plugin directory for installation of the plugin, both of which would have to exist in the directory containing the specified plugin source file. On could argue to automatically have -SkipWrapper passed when -ScriptingDirectory is specified. Still, supporting so would only add complication to the current parameters offered by Compile-SourceScript in now having to have parameter sets that ensure -SkipWrapper is on when -ScriptingDirectory is passed.

My opinion is simple, as you mentioned:, "Compile-SourceScript is itself a convenient wrapper that is designed to support invocation of the two mods’ compiler wrappers". I agree with the first part that it is a convenient wrapper. But it is more than that, it is a better wrapper and should replace both wrappers compile.exe and compile.sh. And if it is actually a full replacement, -SkipWrapper will be the default behavior and the -SkipWrapper param can be removed.

Now -ScriptingDirectory comes into the picture, since it only makes sense when the actual compiler is called. Thats why i said, whether we implement the -ScriptingDirectory param depends on whether we decide to remove support for wrappers compile.exe and compile.sh.

If Compile-SourceScript is going to be easy and predictable to use, then even the parameters themselves should be given names that accurately represent the functionality they serve. As I’ve described earlier, the scripting directory in both amxmodx and sourcemod isn’t simply a directory containing plugin source files, a.k.a. scripts as they would call, but is one containing the compiler and all default include files that come with the mods. With that in mind, a custom scripting directory would actually be one containing those very files themselves. That means, by convention, that the location of the source file cannot actually live outside a scripting directory. Seeing -ScriptingDirectory as separate from the plugin source file and especially allowing specification of the two as separate parameters goes against the convention set by the mods and would very likely come across as confusing to users of this module, as it has been for me.

Following the same line of thought, if Compile-SourceScript is indeed a replacement wrapper, there is one more argument for it being a better wrapper than the native wrappers compile.exe and compile.sh: Specifying -ScriptingDirectory is that it allows better developer workflow by separating plugin source code from the compiler. Now the developer can 1) choose a desired compiler 2) Keep plugin source code it its own repo, away from the compiler.

I think supporting this change requires more thought than it may seem to require. If anything, I think the module shouldn’t be overly restrictive as a compiling solution or make the mistake of becoming confusing to users. Remember that the compilers themselves take in parameters. I think anyone who sufficiently wishes to have their compile process customized (source file path, compiled directory path, installation/copy processes), may as well do so with their own scripts for directly invoking the compiler and not the compile wrapper. It would not surprise me if anyone would much rather do so than use Compile-SourceScript if the module ends up coming across as limiting and unintuitive.

The most intuitive way to use this module is:

Get-Item C:/path/to/my.sp | Compile-SourceScript -Force

where, as i argued earlier, there is no support for native wrappers, and -SkipWrapper is the default behavior and removed.


You may wish to go over the thread carefully starting from #2 (comment).

So if you followed my arguments, as I mentioned in https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-623283605, whether this PR is implemented depends on whether -SkipWrapper is made default behavior and wrapper support is removed altogether, so where the developer intuitively knows how to use the module:

Get-Item C:/path/to/my.sp | Compile-SourceScript -Force -ScriptingDirectory C:/path/to/some/compiler/scripting
leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

I think by now you already should know my stance on this PR.

Not exactly clear. As you've mentioned further up in https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-623198202, adding ScriptingDirectory will require -SkipWrapper to be passed. So it's all about whether we decide to make -SkipWrapper the default, and more wrapper support altogether.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Make non-zero exit code available when compiler compile fails

There's some failed checks.

As discussed in https://github.com/startersclan/Compile-SourceScript/pull/2#issuecomment-623267891, if we decide to no longer support wrappers compile.exe and compile.sh which do not provide proper exit codes, then this PR it will be much easier to fix existing failed checks.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

Yes, we can support piping and specification of multiple plugin source files in future.

Yes, it is to be expected, much like Get-Item and Get-ChildItem which allows [string] and [array] objects passed to -File.

I'll say it's a neat feature to have, though not exactly useful since users would usually be compiling one plugin at a time.

The module also checks for differing hashes right before and after compilation. Due to the statefulness of the compiled directory, I felt it was important to perform the check especially in the case where -Force isn't specified, wherein some plugins may have changed from the time the user compiles the plugin and before the decision to install the plugin is made, and how the user will be alerted of all other plugins that have changed within the compiled directory since the beginning of the compilation process.

Yes, this interactive feature of being able to decide whether to compile and install or simply compile is another bonus of this wrapper. Would be good if the readme listed exactly how this module helps developer workflow.

Care to contribute what you can to the repo?

I can contribute both PRs, but I fear merge conflicts, so i prefer to solve this PR as well as #7 first

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

Yes, we can support piping and specification of multiple plugin source files in future.

Yes, it is to be expected, much like Get-Item and Get-ChildItem which allows [string] and [array] objects passed to -File.

The module also checks for differing hashes right before and after compilation. Due to the statefulness of the compiled directory, I felt it was important to perform the check especially in the case where -Force isn't specified, wherein some plugins may have changed from the time the user compiles the plugin and before the decision to install the plugin is made, and how the user will be alerted of all other plugins that have changed within the compiled directory since the beginning of the compilation process.

Yes, this interactive feature of being able to decide whether to compile and install or simply compile is another bonus of this wrapper. Would be good if the readme listed exactly how this module helps developer workflow.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

I think you need to think things through instead of dishing out quick replies.

As I've pointed out in #2 (comment), it's a good feature to support invocation of the wrapper script because it does provide some usefulness on Windows.

On windows one could do

# By pipeline
Get-Item C:/path/to/scripting/*.sp | Compile-SourceScript -SkipWrapper -Force
# By array (not yet supported)
Compile-SourceScript -SourceFile (Get-Item C:/path/to/scripting/*.sp) -SkipWrapper -Force

which compiles all files in the `scripting` directory.

An important behavior to note is, should the wrapper script be invoked causing all unspecified plugins to be compiled, all successfully compiled plugins will end up in the compiled directory as though users directly executed the default compiler wrapper - the difference lies in how only the specified plugin will be installed in the plugins directory.

Yes, this is the one feature that differentiates this wrapper drastically from the original wrappers compile.sh and compile.exe.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

This is a terrible idea. Proprietary files should be avoided at all costs.

Agreed. But it would "cache" better than the original wrapper.

So let's keep the module simple and straightforward to use.

To keep it simple, -SkipWrapper should be the default behavior. Wrapper calling wrapper should no longer be supported.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

I know it isn't reliable, but it works pretty well especially on Windows, as I've found -SkipWrapper to be useful for compiling sourcemod plugins. Removing the option to invoke the wrapper script will remove the usefulness that comes along with it.

We could support our own version of compiled.dat (or named something else) which contains a filename and a hash instead.

Unless the module transforms into a particularly intelligent wrapper script while maintaining ease of use, I doubt it would match up to users writing a simple script for invoking the compiler with exact precision without the need for PowerShell, Compile-SourceScript, or being limited by the parameters supported by the module.

yes. So the module should be solving problems for a majority of users, except those power users. It should not be too complicated.

Even hacking up shell scripts will still have to deal juggling between using windows / nix compilers and their wrappers by checking for the platform, are less extensible, less testable, and is not as platform-agnostic as Powershell.

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

I've indeed thought about having -Skipwrapper be the default behavior. Yet, I think an important element of what the module solves is checking the compiled directory for changes since the compilation was run, as well as installing the plugin into the plugins directory. These work in accordance to the conventions of both amxmodx and sourcemod, which should work well for most users of the module who are likely developers of plugin themselves.

Yes. It's is a better wrapper.

Another important reason for having provided the choice for invoking the compiler or the compiler wrapper is in how the plugin needn't be recompiled if possible. On Windows, sourcemod's compiler wrapper compile.exe prevents the plugin from having to be compiled unnecessarily by recording the last successful compile date in compile.txt that I think is checked against the matching plugin's modified date, but not the compiler. The same is true for Windows's amxmodx's compiler amxxpc.exe, but not the compiler wrapper compile.exe. On Linux, plugins are always re-compiled regardless of changes. So really, the option is simply for ease of development, and should come across as familiar for users of the module, granting the option should they know the difference between the compilers and their wrappers and how compiling behavior differs on depending on the OS.

To me, tracking whether a source file has changed by modified date is not very reliable. Just do a git checkout on a source file that the "caching" behavior of using compile.txt is gone. I would prefer to assume that each compile should always compile the plugin .

leojonathanoh

comment created time in 3 months

pull request commentstartersclan/Compile-SourceScript

Add optional param to specify scripting directory

Compile-SourceScript is a better wrapper than the included wrappers:

  • amxmodx's compile.sh for *nix, and compile.exe for Windows
  • sourcemod's compile.sh for *nix, and compile.exe for Windows

Would be better if the default behavior was -Skipwrapper, so that it makes it apparent what problem this module is solving, which is to replace the included wrappers.

leojonathanoh

comment created time in 3 months

more