Deploy artifacts to maven central

[pante]

Deploy artifacts to maven central

[Pante]

Elementary 2's on Maven central.

[Pante]

Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?

It's probably not the user agent but some authentication issue, possibly confounded by firewalls swallowing or mutilating requests. You'll have to look into the logs of the Pante repository software (Nexus IIRC), and possibly into the logs of your firewall. @Vlatombe it will help tremendously if you can tell @Pante when exactly the last request was sent, or what public IP or IPs your Artifactory instance is using to talk to the Pante repo (logs tend to contain all sorts of unrelated traffic). @Pante if your firewall was configured competently, then the X-Forwarded-For header will be in your logs. (You may have to configure the web server to show that header; firewalls are expected to add it to requests. The firewalls need to terminate the encryption to do this. If they don't, they need to keep the original IP packet intact, including sender IP, and accept outgoing packets to that IP; in that case, there's no X-Forwarded-For.) If this sounds complicated: That's why people tend to avoid hosting their own repositories ;-)

Yikes, I think I'm just going to stick to publishing it on Maven central...

[Pante]

I've submitted the project to Maven Central and it's pending approval, see https://issues.sonatype.org/projects/OSSRH/issues/OSSRH-92508?filter=allopenissues. The downside is that I had to disable HTTPS for repo.karuslabs.com for the time-being in order to add the DNS record... (Don't ask, the hosting infrastructure is ancient)

EDIT: https access is available again.

[Vlatombe]

Publish your Maven artifacts to Maven Central.
This prevents not just overwrites, but also supply-chain attacks like "hack into repo.karuslabs.com and insert malware into the .jar files".

Huge 👍 to that. This library is used in testing parts of the Jenkins ecosystem and it would be really appreciated if this could be deployed to Maven central to avoid configuration of custom mirrors as well as avoiding burden on your own infrastructure.

Additionally it seems your Nexus instance is forbidding Artifactory user agent (used by Jenkinsci infrastructure), which prevents effective proxying of the repository (see jenkins-infra/helpdesk#3115 (comment))

[Pante]

If I remember, this was a one-off thing to correct a dependency issue occurring with 1.1.2. The code in both deployments are (almost) identical with the removal of some compile-time scoped annotations.

. Deploying 1.1.3 was also an option but in my rush to fix the issue, I didn't really think too much about it.

That said, it'll be worth investigating deployment to maven central when we are closer to deploying 1.2.0

[CC007]

Maybe it would help to use GitFlow or GitHubFlow for the branching strategy, so that there's a specific release branch on which to make releases.

That way your automation could use those branches to guarantee that releases are only made on those branches and only when tagged with a specific tag (so it would be impossible to release 1.1.2 on a commit that isn't tagged with 1.1.2)

[Pante]

It was moreso that I intentionally redeployed 1.1.2 without thinking too much about the aftereffects rather than an accidental deployment. That said, I feel that the project should towards a more trunk-based development flow.

The original stable branch was created because I disliked having documentation next to code when I first started the project. That view however has since changed (thankfully) in the 1-2 years since. I'm planning to deprecate the stable branch and tag releases on master in the future.

[CC007]

Yea, right now stable acts a bit like the master branch and master like a develop branch. I don't think that there is anything wrong with that divide though, but it would probably be better to keep the industry standards when it comes to naming these.

[Pante]

Publish your Maven artifacts to Maven Central.
This prevents not just overwrites, but also supply-chain attacks like "hack into repo.karuslabs.com and insert malware into the .jar files".

Huge 👍 to that. This library is used in testing parts of the Jenkins ecosystem and it would be really appreciated if this could be deployed to Maven central to avoid configuration of custom mirrors as well as avoiding burden on your own infrastructure.

Additionally it seems your Nexus instance is forbidding Artifactory user agent (used by Jenkinsci infrastructure), which prevents effective proxying of the repository (see jenkins-infra/helpdesk#3115 (comment))

I'll probably get around to deploying Elementary & Utilitary 2.0.0 this weekend & get the ball rolling on Maven central deployment then. Had to postpone work on it due to school & work commitments.

That said, Satisfactory will probably still remain at 1.1.2 since it is far from complete.

Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?

[toolforger]

Also, I'm not too sure about how to fix the Artifactory user agent issue, any clue what might be the cause?

It's probably not the user agent but some authentication issue, possibly confounded by firewalls swallowing or mutilating requests.
You'll have to look into the logs of the Pante repository software (Nexus IIRC), and possibly into the logs of your firewall.
@Vlatombe it will help tremendously if you can tell @Pante when exactly the last request was sent, or what public IP or IPs your Artifactory instance is using to talk to the Pante repo (logs tend to contain all sorts of unrelated traffic). @Pante if your firewall was configured competently, then the X-Forwarded-For header will be in your logs. (You may have to configure the web server to show that header; firewalls are expected to add it to requests. The firewalls need to terminate the encryption to do this. If they don't, they need to keep the original IP packet intact, including sender IP, and accept outgoing packets to that IP; in that case, there's no X-Forwarded-For.)
If this sounds complicated: That's why people tend to avoid hosting their own repositories ;-)

[toolforger]

Hopefully Maven Central will accept HTTP, otherwise the approval should be fast.
This initial approval is typically pretty fast otherwise, it merely checks that you own the domain so that they allow you to grab the group namespace. The actual project uploads don't need this kind of approval, i.e. you should be able to revert to HTTPS quickly.

[jglick]

The actual project uploads don't need this kind of approval

Right, after onboarding you just need to securely manage signing & upload keys (pending sigstore/sigstore-maven#12).