m88i / aicura Goto Github PK

Add a possibility to list, get and add a new user.

Some times during tests we wish to have objects created in the in memory database before hand. A default Nexus server comes with some default repositories such as maven-central. The Fake client could also have these entries on creation or accept such objects in the constructor. Something like:

nexus.NewFakeClient().
    WithMavenGroups(...).
    WithMavenProxies(...).
    WithUsers(...)

We need a way to fetch the Groovy scripts which will be used in requests.

Proposals:

I thought of two approaches for this. Both of them use a repository pattern which would require callers to be aware of the of the desired script's ID. This could be made more user-friendly by adding enum-like constants to provide idiomatic interface (more on this later on).

We'd store each script in a separate file under a dedicated directory, naming them with their ID (e.g., scripts/1.groovy).

In both approaches, at this point of development, the repository interface would consist of only two methods, as defined below:

type Script string
type ScriptRepository interface {
	Scripts() ([]Script, error)
	ScriptByID(id int) (Script, error)
}

The two mentioned approaches differ on when they fetch the scripts.

1. load a script into memory only when it is requested. This is the slowest but most economic space-wise. Finding the file would take constant time due to the naming scheme being tightly coupled with the script it represents, but loading it from disk will be ultimately slow.
2. load all scripts into a slice indexed by their IDs during initialization. This would require reading all files from disk before being able to process any requests, meaning there will be a slower bootstrap time, but as soon as that is done all requests will be processed in O(1) time. This constantly consumes O(n) memory throughout the whole execution. With this approach we would need to decide if we'll watch the files for changes or not (if desired, could be accomplished using fsnotify) in order to load the updated scripts into memory.

I personally prefer approach 2, I don't think there will be enough scripts for bootstrap to be affected in a major way. If this changes as the project evolves we can consider different strategies (hopefully wiser and with a deeper understanding of the domain), but for now I believe this is perfectly fine. I also believe watching the script files for changes now is overkill, but we ought to keep that in mind in case we provide users with a mechanism to insert their own scripts in the future (though that would probably render some other changes in the repository's behavior).

In order to make it friendlier to use, we could maintain integer constants which describe the script's functionality so that we don't need to remember a script's ID, only what it does. For example:

const (
	BackupActivityScriptID  = 1
	CountComponentsScriptID = 2
)

Callers would then be able to run repository.ScriptByID(BackupActivityScriptID).

Another option is to store scripts with names that reveal something about them and have the repository load them into a map indexed by their file name. This approach could be facilitated by the same enum-like constants, but IMO that only complicates things with little benefit: there's no need for humans to understand what each script does from its file name, they are only there to be processed by the program.

Sometimes we need to do some operations with different users using the same instance, would be nice to have an interface to change the credentials after having the instance created.

Add the possibility do add new repositories

• How do we suppose to authenticate into the Nexus3 server with the client?
• How to handle authentication programmatically?

Good reference: https://tutorialedge.net/golang/improving-your-tests-with-testify-go/

Since now we depend on beta path in the REST API, which is available only on newer versions, would be nice to have a small interface to check if the given server has the API available. A simple request to the /beta/security/user-sources would do. Needs authentication.

The maven-public repository needs to be updated to add more repositories to it

We might need to change the types to pointers instead.