Add private repository on initialization - python-poetry

According to the documentation, if you wish to use a private repository you need to add a stanza to the pyproject.toml by hand. Is it possible to configure poetry so that it's added automatically whenever the poetry new command is run?

Related

Create conan package for specific commit ID and use it as dependencies on other packages

I am currently using Jenkins to build C/C++ projects. The projects uses conan packages as dependencies. I am trying to create a package with specific commit ID which can be later used by other packages.
For example:
RepoA is dependent on package created by RepoB. When RepoA build is trigged in jenkins RepoB build is triggered first in the pipeline and the packages are deployed in local cache which can be used by the RepoA later from the local cache.
RepoA has branch name called X and RepoB will also have same branch name called X. I need to use packages created from RepoB branch X for RepoA. Is there a way in conan to make RepoA use package created from RepoB branch X. I already can use the branch name as channel and use the right packages accordingly for RepoA as the branch name will be kept same. But apart from using the branch name is there any other way to create packages with commit ID as package ID and use it later for RepoA. If anyone knows the answer would be a great help.
The link below explains different package revision but I am cannot get a grasp of how to use it. It would be great if someone can give an example for the solution
Conan package revisions

How to use custom settings.xml with GitLab-CI Auto DevOps?

I'm using GitLab CI Auto DevOps to compile a project based on Maven based in a DinD (docker-in-docker) runner.
CI job start, and buildpack for Maven is correctly detected (based on herokuish).
How can I configure a custom settings file without switching to a custom .gitlab-ci.yml?
I would like to continue using Auto DevOps.
Because maven needs access to a private repository based on Nexus it is convenient to configure a custom settings.xml (and version it with your source code)
The easiest solution is to include a custom settings.xml. This feature was included in the corresponding buildpack used by Auto DevOps some time ago, as you can see in this article from Heroku buildpacks about "Using a Custom Maven Settings File".
So I defined MAVEN_SETTINGS_PATH variable in .gitlab-ci.yml config file:
variables:
- MAVEN_SETTINGS_PATH: ".m2/settings.xml"
Then, included the file settings.xml in the repository.
Avoid to include secrets or another sensible information
When using a private maven repository with credentials
Finally, you can define in Gitlab some variables to be used in settings.xml. Using Gitlab UI or API add variables for the user, password, and repository url, to be included as environment variables from Gitlab into the job. Then you can use it in settingx.xml like ${env.VARIABLE_NAME}
Example of Gitlab-CI configuration file:
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
MAVEN_SETTINGS_PATH: ".m2/settings.xml"
AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: NEXUS_REPO_USER,NEXUS_REPO_PASSWORD,NEXUS_REPO_URL
As a final recommendation, you should avoid to use passwords in environment variables, use native methods from your environment for credentials storage is recommended.

build go project in Jenkins with dependencies in private repository

I'm trying to set up automated build for go projects. Most people just use github dependencies which don't need credentials. We have some internal dependencies however available on our private git central server. Credentials are needed however to have go access these.
A possible workaround would be to configure a global git variable inside our build machines / build dockers; something like:
git config --global url."https://user:password#private.git.server/".insteadOf "https://private.git.server/"
however this doesn't seem to be the best solution to me, since the password would be stored in a human-readable text file.
I think the git-credentials plugin should be able to help me out; could I maybe export GIT_TERMINAL_PROMPT=1 and let the git-credentials plugin fill in for me?
How could I make sure go get or go install gets access to our private repository in a secure way?
I use a workaround with GITHUB_TOKEN to solve this.
Generate GITHUB_TOKEN here https://github.com/settings/tokens
export GITHUB_TOKEN=xxx
git config --global url."https://${GITHUB_TOKEN}:x-oauth-basic#github.com/mycompany".insteadOf "https://github.com/mycompany"
This way you don't expose the password and can revoke token at any time.
Note: Go uses http when downloading dependencies, not ssh.

using ansible modules from git repository?

I have a playbook and a bunch of modules I wrote.
Now I want to reuse the same modules in my next playbook for a different project.
I really want to push those modules to a public git repository and then somehow tell ansible to use the modules from the git repository.
(kinda like npm package.json referencing github)
I can't seem to find any documentation on how to do that.
For now, I am using a workaround where I tell people to npm install the repository, and then define ANSIBLE_LIBRARY variable.
How can I tell the playbook to load modules from a github repository or some other remote location?
Actually modules can be nested inside roles since quite a long time. Since Ansible 2 this even is possible with most of the plugins.
The folders where the modules & plugins need to be stored inside the role is the same as on playbook level. Modules go into library, plugins go into *_plugins (action_plugins, callback_plugins, filter_plugins etc)
To make the module/plugin then available the role has to be applied to the playbook (or added as a dependency of another role)
Only exception known to me are variable plugins and that perfectly makes sense. Since variable plugins are executed when the inventory is read, which happens before roles are interpreted.
vars_plugins still can be distributed in roles, but the path needs to be added in the ansible.cfg. Fortunately you can also use wildcards in paths:
vars_plugins = roles/*/vars_plugins
And no, all of this is not documented in any way. :)
Finally, to distribute roles you can use Ansible Galaxy:
ansible-galaxy install foo
Nothing wrong with directly using git. Ansible Galaxy actually only is a tool to install git repositories. But since Galaxy is the Ansible standard I suggest to at least provide a Galaxy compatible format. A good (best?) practice how to install Galaxy roles separate from the projects roles can be found here.
Here's an example for an action plugin: https://galaxy.ansible.com/udondan/ssh-reconnect/
There is no solution for that at the moment. Maybe you can add a playbook to download the modules to your project to avoid npm, but thats even not that nice.
I have my custom modules in a directory next to my playbooks. This directory is defined in my global ansible.cfg file:
library = /usr/share/ansible
The only drawbag here is that i allways have the same version for modules on all playbboks.

How to configure Typesafe Activator *a priori* to use an existing local Maven repository?

(Not found in the Activator documentation)
It seems that it is possible to have Activator also use an existing local Maven repository by adding the following entry (in bold) in file build.sbt:
resolvers += Seq(
"Local Maven Repository" at "file://q:/repositories/maven",
"Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"
)
I am not sure it works but anyway, the problem with this approach is that the project structure must already have been created (and therefore a local repository created and automatically populated by downloads), hence my question : is it possible to tell Activator before it creates the project structure that it should use some local Maven repository ?
Thanks in advance for any hint.
Activator makes use of the sbt-launcher. You can use the sbt-launcher to control which repositories sbt makes use of by default for each project and for the launcher itself.
If you'd like to modify the activator launcher itself, unzip the jar file and take a look at the sbt/boot.properties file included. You can use the format outlined at sbt's launcher docs to add your local maven repository to the list.
A simpler option in the future (but not enabled in our current properties file) is the launcher's ability to have an override repository configuration file. See: Sbt's proxy configuration docs. This file would allow you to specify the repositories you wish activator to use by default. We disabled this to ensure the offline repository which activator uses is added by default. However, I'll open a ticket to re-enable this feature. That way, you should be able to just create a ~/.sbt/repositories file with the following contents:
[repositories]
activator-local: file://${activator.local.repository-${activator.home-${user.home}/.activator}/repository}, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
local
maven-local
maven-central
typesafe-releases: http://typesafe.artifactoryonline.com/typesafe/releases
typesafe-ivy-releases: http://typesafe.artifactoryonline.com/typesafe/ivy-releases, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
Note: the ~/.sbt/boot directory will always exist. This is created to ensure that no other process deletes jar files we use while running, so we copy these out of the local cache. If we didn't, you'd see some really fun error messages.

Resources